Also fixes some issues in ThinGL where extensions weren't being used.

#628)

Both the TRANSLUCENT and TRIPWIRE render layers are rendered with translucency,
however Sodium treats the TRIPWIRE render layer as if it were opaque for the
purposes of determining whether chunks should be sorted back to front or front
to back.

The slider thumb in the slider control previously could render outside of the slider area when the value of the slider was outside of its maximum range. While this shouldn't happen during normal use, it could occur if the game options file was manually edited, which is common in speedrunning when the player wants maximum brightness. Instead of having the slider thumb render outside of the slider area when situations like this occur, we can limit its position to be within the minimum and maximum values of the slider.

Previously, when adjusting a value using the slider control, the range of the mouse was shortened by 4 pixels on each side. This meant that if the mouse was four pixels inside from the left of the slider, the value would incorrectly set as the minimum. This offset has been removed to make the positioning of the slider control and the set value the same, preventing "drift" of the slider thumb.

Previously, control elements kept their fields when modified options were undone. This caused issues when changing a control element and pressing "Undo," because fields such as the slider position of the slider control or the current index of the cycle control were not reset. To solve these issues, the control elements that need to be reset on undo now implement a reset interface, which allows them to reset these fields.

Removes the resettable interface, because we can update the values through existing methods in each control instead.

Co-authored-by: Yao Chung Hu <[email protected]>

The current and modified option values in the Sodium options need to be compared to see if the value is changed or not. Previously, this was done using the == operator. However, since the current and modified options are wrapper types, it will compare them as references, making them inequal when their values are the same. This issue does not happen in a majority of the Sodium options, since Java may cache the objects as values. To solve this issue, the current and modified options can be compared using equals(), which will compare by value instead.

Previously, button widgets that were not visible could be clicked on, since only the enabled state of the button was considered if action should be taken or not. To fix this issue, button widgets will also consider their own visibility state when taking action after a click.

Previously, the rendering of rectangles and quads in the Sodium GUI was defined using integers. This restricted the position of widgets to each in-game pixel, meaning using a scaled GUI scale would cause the rendered position to be incorrect in some scenarios. For example, a user on a HiDPI display using a GUI scale of 8 would not see the brightness slider thumb move when setting it from 0 to 1, because it must be aligned to every in-game pixel (in this scenario, each in-game pixel is 8 real pixels on the display, because of a GUI scale of 8). To solve this, the rendering of rectangles and quads now uses doubles to define position, allowing for greater positioning precision when needed.

This is one of my messier commits, but it's late and trying
to break this up is too much work.

- Fixed some occlusion culling problems caused by the chunk building
  step not always updating a position vector, resulting in the occlusion
  data having data set for the previous block position when an air block
  is encountered.

- Split world slicing into two stages to enable faster render task
  creation. This introduces a lot of changes, but primarily means the
  main render thread can simply focus on copying memory to a new thread
  without needing to unpack it immediately.

- Fixed a problem where vertex lighting was reading from the client world object
  directly instead of our copied slice, resulting in horrible performance
  and thread safety problems.

# Conflicts:
#	src/main/java/me/jellysquid/mods/sodium/client/gui/SodiumGameOptions.java

Several mods (primarily LambdaBetterGrass) require extra context in chunk rendering, that isn't provided by the 18x18x18 (5832 blocks) chunk section copy that Sodium makes. This change increases it to 20x20x20 (8000 blocks), which matches vanilla - so all mods should expect to have this radius of context for rendering. Unfortunately, as more blocks are being copied, this will impact chunk building performance very slightly, though much better than my original 48x48x48 change.

Other methods for increasing this radius without affecting performance (as this is very hot code) may be worth exploring, though it may not be worth the additional complexity.

The change has been tested in my Sodium fork, though the performance implications have not been directly measured.

Closes #673

Closes #262

Merges #672

Co-authored-by: FionaTheMortal <[email protected]>

Not sure what Git is doing here.

(this has been bugging me for a long while)

…n copyBufferSubData

Allows for F3 hotkeys to work, since they don't go through our video settings screen.
This is kind of a hack, but it's what vanilla does anyways.

Helps to improve performance on AMD/NVIDIA GPUs